1. Field of the Invention
This invention relates to software development tools, particularly to software tools that support the development, test, and integration of digital system components that communicate with each other over a data bus.
2. Background of the Invention
In a network of distributed components, wherein data is transmitted between them during operation, testing of individual components requires a simulation/stimulation of the component under testing to evaluate its operation. The traditional challenges of test and integration of such system components are well understood, and include the limited test functionality of the actual system and components thereof, parallel development of several components requiring parallel testing, and design performance standards that predicate that the components under testing achieve a certain level of qualification before integrating it with other components. These conditions necessitate the use of test equipment that can somehow temporarily replace, or “emulate” the system environment so that components under test can be properly evaluated. Traditionally, engineers have resorted to two solutions to these problems: either a bus analyzer that permits monitoring of actual machine-formatted data transmitted in the system or an emulator that translates such data for a user while testing.
Bus analyzers can monitor and display raw data that has been transmitted over a network data bus (for example, Ethernet TCP/IP, or MIL-STD-1553) between system components. These applications also typically enable the user to define message data and transmit that data to a system component, thus acting as a rudimentary system component emulator, without the human-readable features.
When viewing or defining message data with a bus analyzer, the test engineer must decode or encode the message data himself/herself, as bus analyzers display data in “raw” format (usually hexadecimal). To do this, the engineer looks up the message type in question in the documented interface specification, and manually, using a scientific calculator or his own mind, encodes or decodes the raw message data. Generally, an engineer will expend much of his/her test and integration activity performing this encoding and decoding process. Unfortunately, the bus analyzer cannot decode the raw data into something meaningful for the user, because the bus analyzer has no knowledge of the interface specification.
An alternative solution for testing is a System Component Emulator (SCE). For this solution, an engineer will develop a software application which will “emulate” a particular system component. This means that the SCE will encode messages to, and decode messages from, the component under testing automatically in a manner exactly consistent with the requirements specification Oust as the component the SCE emulates would). As a consequence, the SCE can then represent the message data in a meaningful, human-readable format to the user. The SCE, therefore, automates the encoding and decoding of message data that the engineer would otherwise do manually with a bus monitor.
Also, an engineer may develop a complementary application that acts as a human-readable bus monitor, rather than a human-readable emulator. That is, rather than replace a system component, the application monitors the data messages passed between components, and displays them in a human-readable format. Software engineers must develop a human-readable emulator or monitor by writing the message encoding and decoding algorithms with respect to documented interface requirements. The resulting software application emulates or monitors one system component.
Compared to the bus analyzer, an SCE provides an advantage to the user by performing the encoding and decoding of the message data automatically. This enables the user to always deal with the message data in a meaningful, human-readable way, saving the engineer the time and effort it takes to encode and decode message data manually (i.e. “in his/her own head”) with established interface specifications.
However, an SCE exhibits some disadvantages compared to a bus analyzer. First, an engineer or team of engineers must develop it from scratch, rather than simply purchasing an off-the-shelf bus analyzer. These development efforts consume money and valuable man-hours that managers would otherwise allocate to other engineering and development activities. Second, and more importantly, engineers typically develop SCEs to only emulate one system component, whereas a bus analyzer can mimic any system component. This means they have to repeat this development effort for every system component they need to emulate. Third, if the interface specification changes, this means expending more man-hours making corresponding changes to the SCE on top of the man-hours it takes to make the changes to the components in the system and the component under test (CUT).
A bus analyzer forces the tester to engage in the manual, time-consuming process of encoding and decoding message data that passes between the CUT and the rest of the system. However, after the organization purchases one, no time and money are involved. On the other hand, a SCE encodes and decodes message data automatically for the user, but can only be used as an emulator of one component, and takes a significant investment of time and money to develop and maintain.
There is a need, therefor, for an improved device which can emulate a variety of components, monitor, display and define their communications in human readable form, record communications, and automate communications without requiring human intervention.